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1 TRANSACTION DATA TRANSLATION SYSTEM 

2 BACKGROUND OF THE INVENTION 

3 Field of the Invention 

4 The present invention relates to a system and method for data translation, and more 



5 particularly, to a system and method for the translation of financial transaction data in the 

6 environment of operational databases. 

7 Brief Description of Related Art 



8 Analytic and Operational Databases 

[39 Conventional software applications typically utilize databases stored in computer- 

3iO readable memory for storing associated data. A database is a computerized record-keeping 

^ J 1 system involving data, hardware on which the data is physically stored, and software capable of 



:i2 accessing the hardware to provide a standard method for storing, retrieving or modifying the 

Lis data. Paper-based "databases", such as libraries and filing cabinet-type filing/storage/retrieval 

134 systems, have long been in existence. Computerized databases evolved in the 1960s to solve 

Ms problems associated with paper-based databases, including enormous physical space 

16 requirements, slow access to data, complexity to learn and use, inability to continually keep data 

17 adequately updated, lack of accuracy, difficulty in sharing data between multiple users, and lack 

18 of security. Computerized databases solved these problems by providing a compact, fast, easy to 

19 use, cxirrent, accurate, shareable and secure means for storing, obtaining and modifying data, 

20 regardless of the amount of data being handled. Traditional computer databases for business 

21 appUcations, including Oracle™ and Sybase SQL Server™ ran on large mainframe computers. 

22 As personal computers became less expensive and more powerful, the average computer user 



1 began utilizing databases, such as dBase ™ and Microsoft Access , for a variety of 

2 applications. 

3 With the recent growth of the Internet and the World Wide Web, databases now 

4 constitute an integral part of many web sites, particularly those delivering content to users and 

5 permitting users to transact business over the Internet. For example, an online database of 

6 information such as stock quotes or magazine articles typically permits users to retrieve desired 

7 information by browsing the information stored on its database by category or searching the 

8 database for specific items. The type of database in the foregoing example is called an analytic 

0 9 database, or OLAP (On-Line Analytic Processing), and is one of two main categories of 

flO databases. An analytic database is primarily a static, read-only database for storing historical or 

}^ 1 archived data for purposes of analysis. Another example of the use of an analytic database 

ifi 2 would be storing information about sales of homes in a city over a certain period of time, for 

01 3 purposes of analyzing marketing strategies in relation to demographics. 

014 Substantially unlike the analytic database, the second category of database is the 

Ql 5 operational database, or OLTP (On-Line Transaction Processing), which facilitates and manages 

16 transaction-oriented applications. An operational database facilitates modifying (i.e. adding, 

1 7 changing, or deleting) data, thus providing a means for managing information which is more 

18 dynamic than in an analytic database. Operational databases are typically used to track 

19 information which is updated in real time. An example of an operational database is a database 

20 used to track inventory in a warehouse supplying a web-based online store. In such a scenario, 

2 1 information stored in the operational database would be dynamically updated as customers order 

22 products from the store. The database would typically be configured to track the number of 

23 items sold and to provide notification when a reorder of stock is needed. Industries utilizing 
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1 operational databases generally include those requiring large numbers of data entry and retrieval 

2 transactions, such as banking, airlines, mail order, e-commerce, supermarkets, and 

3 manufacturers. Due to the massive volume of information inherent in most operational 

4 databases, modem online transaction processing increasingly requires support for transactions 

5 that span a network and may include multiple entities. For this reason, many operational 

6 database software applications use client-server processing and brokering software that allows 

7 transactions to run on different computer platforms within a network, such as a local-area 

8 network, wide-area network, or the Internet. 

O 9 While operational databases facilitate modification of data, the modification is not 

1^0 usually achieved by directly accessing the data in the database. Instead, a "transaction" is used 

11 1 to add, modify, or delete database data. A transaction (e.g. a SAP iDOC) is an instruction to 

Ift2 alter data in the database along with the appropriate data for carrying out the alteration, i.e. data 

131 3 is input and changed in the tables by an application executing transactions. A transaction, 

1314 depending on its nature, can involve the manipulation of only a few fields, hundreds of fields, or 
S3l 5 a very large number of fields. A business relying on an operational database in its operations has 

16 predefined transactions which enable the business to operate. Proper execution of these 

17 transactions is required to keep the business running properly. Businesses typically hire 

18 consuUants to help in defining the required transactions, as well as to design and author software 

1 9 applications which perform the required transactions in the operational database. 

20 Electronic Data Interchange (EDD 

21 Transactions performed on databases no longer need to be executed locally at the 

22 computer on which the database resides. Although modems and various local and wide area 

23 networks have been available for some time to allow transactions to be remotely executed, the 
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1 recent growth of the IntemetAVorld Wide Web has made it inexpensive and relatively simple for 

2 geographically remote entities to perform transactions on the databases of one another, 

3 particularly due to the advent of new server technology and sophisticated online security 

4 systems. 

5 Whether by modem, network, internet, or other means, EDI (electronic data 

6 interchange) is the cormnon method used to send information from one computer to another. EDI 

7 can also be described as the computer-to-computer exchange of routine business transactions in a 

8 standard format between organizations. EDI is a critical part of electronic commerce because it 
3 9 enables computers to exchange data electronically, which is much faster, cheaper, and more 

h 0 accurate than a paper-based system. To gain the maximum benefits of EDI, an organization's 

^1 1 systems must have two characteristics. First, the flow of information must be integrated, i.e., the 

Kl2 data must flow between automated business management systems using EDI software without 

-il3 being re-keyed. Second, the automated business management systems must be inteUigent, i.e. 

314 these systems must be able to automatically process routine transactions according to those limits 

3 1 5 defined by the businesses conducting trade. 

1 6 EDI transactions represent paperless business information exchanges that are 

17 independent of either partner's unique business processes, computer software, or hardware. This 

1 8 approach provides flexibility and does not impose the requirement of common hardware, 

19 software, business processes, or terminology upon the diverse participants, only common data 

20 usage and transmission formats. Even if EDI is used to simply replace paper while leaving the 

21 existing business processes in place, benefits include reduced data entry and mailing costs, more 

22 accurate information, faster communications, and decreased paperwork and reproduction. 

23 However, fiiUy exploiting the EDI potential requires reengineering the business to bring about 
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1 the greater advantages of faster processing of actions, availability of timely and accurate data for 

2 decision-makers, lower personnel requirements, and a responsive environment that supports 

3 innovations, such as direct vendor delivery, flexible manufacturing, rapid distribution, and 

4 central pay. 

5 In 1979, the American National Standards Institute (ANSI), which is the clearinghouse 

6 and coordinator for standards in all areas of trade and commerce, chartered the Accredited 

7 Standards Committee (ASC) X12 to develop and maintain standards for EDI. The ASC is 

8 composed of voluntary representatives from industry, labor, consumer, and government to 

Q 9 prepare consensus standards. Upon pubUc comment and approval, ANSI ASCs publish national 

i^O standards. ANSI X12 standards, usually simply referred to as X12, are the most commonly used 

111 1 EDI standards in North America. ASC X 1 2 was chartered to handle business transactions but 

IS 1 2 has been expanded to include many other transactions and industries. For example, the Federal 

013 Information Processing Standard Publication 161 (FIPS-161) dated September 1991 requires all 

D 14 Federal agencies that exchange business information electronically to use existing X12 

13 15 standards. The transactions involved in EDI are data descriptions of business functions, such as 

16 invoicing, purchasing, applications, etc. Standards are defined as the technical documentation 

17 approved by the ASC XI2, including transaction sets, segments, data elements, code set, and 

1 8 mterchange control structure. Standards prescribe the framework for formatting a specific EDI 

1 9 message (or "transaction"), i.e. a block of information making up a business transaction or part 

20 of a business transaction, and each type of transaction or "transaction set" is identified by a 3- 

2 1 digit number. As of 1 999, there were almost two hundred transaction sets supporting the 

22 following business areas: communications and controls, product data, finance, government. 
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1 materials management, transportation, purchasing, industry standards transition, distribution and 

2 warehousing, and insurance. 

3 For example, each transaction set used in the Department of Defense EDI meets ANSI 

4 XI 2 criteria and is designed to replace a paper "document" currently used in the paper-based 

5 procurement process. In this scenario, transaction set 840 is a request for quotation (RFQ). The 

6 840 transaction set provides the information that is required to conduct a business action 

7 consisting of transmitting a RFQ. Likewise, an 843 transaction set is the trading partner's 

8 response to the RFQ, and fmally, the 850 transaction set is the purchase order issued by the 
5 9 Department of Defense. Another example is the use of EDI in health care eligibility 

0 transactions, in which the 270 is the inquiry transaction, which allows a health care provider to 

1ft 1 ask a detailed question about coverage of an individual for a benefit. It identifies the provider 

ml2 making the inquiry, the individual who is the subject of the inquiry, and the benefit being 

013 inquired about. Transaction 271 is the response to this inquiry, and is able to convey detailed 

a 14 information describing the benefits, restrictions, limitations, co-pay amounts, remaining visits, 

C 15 and so forth. The 27 1 is also used within managed care environments to convey information 

1 6 describing health plan benefit packages and membership rosters. 

17 The ANSI ASC X12 "standards" are essentially a uniform syntax for packaging ASCII 

1 8 data items, along with a set of standard, predefined code-table values and cross-references. The 

19 syntax is simple, applying a hghtly-structured set of labels and positional rules, and a looping 

20 structure, on ordinary ASCII characters. The key feature of an X12 standard message is that it is 

2 1 totally independent of the mechanical means of transmittal of information. The standards are for 

22 the interchange of data: information can be coded in X 1 2 on one platform and application 

23 program, and transmitted ~ using floppy diskette, magnetic tape, or by any type of real-time or 
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1 batch or packet telecommunication, or a combination of these methods - to any other platform 

2 and application program having an electronic X12 interpreter. The standards control simply the 

3 coding format used, rather than the transmission method. 

4 ANSI ASC X12 syntax rules and code values are organized at four levels of detail 

5 (listed here from the most detailed to the highest level of generality): data element dictionary, 

6 segment directory and positional rules, transaction set standards, and transmission control 

7 standards. From the most general to the most detailed, the X12 standards work as follows: The 

8 transmission (or interchange) control standards provide for the overall electronic envelope in 

9 which one or more X12 messages are carried from sender to receiver(s). Each interchange 

10 consists of one or more transaction sets. Each transaction set is roughly equivalent to a generic 

1 1 "type" of business paper document, such as an Invoice, or a Purchase Order, or a Report of Test 

12 Results. Each type of transaction set, in turn, is made up of a series of "segments" -- each 

13 roughly equivalent to a "line", "block", or "field" of related data on a paper form. Finally, at the 

14 most detailed level, the data element dictionary provides definitions for the "data elements" - 

1 5 individual atoms of data which are assembled to compose each segment of information in the 

16 electronic transaction. 

1 7 The data element dictionary defines the data elements that can be transmitted and 

1 8 provides a standard identifying code for each element. Data elements are the XI 2 "atoms", the 

19 basic building blocks of the record being transmitted. For example, in the environmental arena, 

20 these can include alphanumeric elements such as the name and address of a facility, its permit 

2 1 number or waste ID code, or numerical data such as flow rate, concentration, or statistical 

22 sampling parameters. Additionally, the X12 dictionary contains tables of predefined code values 

23 for commonly encountered items of business data. An example of data elements often found 
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1 together are the telephone number of a point of contact; the X12 reference code is "TE," which 

2 when encountered tells the receiver that the following data item (e.g. "603-555-1212") should be 

3 interpreted as a telephone number rather than a fax or pager number. The value "TE" is an 

4 example of a standard, predefined X12 code value, and the phone number itself is an example of 

5 a user-supplied value. The X12 standards provide a powerful combination of predictable 

6 positions -- or data "pigeonholes" - in which to place or find both kinds of elements of data. 

7 The segment directory gives the code names and positional rules for logical and 

8 predefined combinations of related data elements. For example, the segment directory shows a 

9 combination called "DTM" specifying that "date-and-time" usually has three related data 

10 elements. The first might be a code number or character indicating the kind of date to follow, 

1 1 such as shipping date, invoice date, publication date, or other pre-specified date. The second 

12 element would contain the date itself, using six digits, and the third would be the time of day. 

1 3 Special characters separate data elements within a segment, and mark the termination of each 

14 segment and the beginning of the next segment. Another example of a segment might be the 

15 name and telephone number of the "person to contact" which is coded in X12 as: 

16 PER*1C*W.M. Smith*TE*6035551234*N/L 

17 where "PER" is the identifier for the segment, and "IC" and 'TE" are the reference codes for 

1 8 person name (W.M. Smith) and phone number (603555 1234). "N/L" signifies end of segment. 

19 The transaction set standards define the contents of a single generic type of document, 

20 such as invoices, purchase orders, requests for quotation, and shipping manifests. As seen in the 

2 1 examples above, the X12 committee uses a three-digit number for each type of electi-onic 

22 document. As an example, a purchase order has a standard-development ti-ack number of 850, 

23 the invoice is an 8 1 0, and a request for quotation is an 840. While a standard ID number is under 
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1 review, it carries a prefix of "dp" (for draft proposed). Returning to the example of the 

2 environmental arena, transaction set standards would be developed for facility inventory forms, 

3 monitoring reports, or other documents of a similar type. The standards simply define the data 

4 segments which make up the document in the order they are to be transmitted. For the user, it is 

5 transmission of the transaction set which is the real purpose for the entire effort. 

6 Transmission control standards define the "envelope", or the "letter of transmittal" for 

7 the transmission of the electronic documents (i.e., transaction sets). They define such items as: 

8 how transaction sets are identified and how beginnings and endings of the documents are 

9 defined, grouping of the sets, identification of sender and receiver, and procedures for 

1 0 transmitting and for acknowledging receipt. These standards also estabUsh means by which 

1 1 documents of similar type are grouped for transmission, and provide means by which more than 

12 one category of document can be forwarded in one transmission. 

13 In practice, the originator of an electronic message uses the X12 standards to construct 

14 a message which could be easily interpreted by a recipient familiar with X12, or, more 

1 5 importantly, the recipient's data processing equipment. The originator looks in the data element 

1 6 dictionary to identify how each element in his message should be coded. Then the sender must 

17 sequence each of those elements m the order established in the segment dictionary. Each of those 

1 8 segments is in ttim placed in a segment sequence specified in the transactions set. The originator 

19 separates data elements within a segment with some predefmed symbol, such as an asterisk, then 

20 separates segments with other symbols such as "N/L". The result is a computer message which 

21 corresponds to a single hardcopy document -- a transaction set built from predefmed segments 

22 made up of predefmed data elements in a predefined order. 
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1 Several types of documents might be combined in a single transmission. For example, 

2 an originator might wish to transmit five invoices, fourteen purchase orders, and three requests 

3 for quotation in one session. The sender would simply group all similar documents together. At 

4 the start of the session, an interchange control header would be sent, followed by a functional 

5 group header indicating invoices are to be transmitted, then the five invoices, with transaction set 

6 headers and trailers separating each invoice, followed by a functional group trailer indicating end 

7 of transmission of invoices. The process would be repeated for the purchase orders (functional 

8 group header, invoices with headers and trailers, and functional group trailer), and then again for 

9 the three requests for quotation. Thus, each of the twenty-two individual documents could be 

1 0 viewed as the equivalent of a complete paper document. In the paper world, the sender might 

1 1 decide to forward all twenty-two paper documents to the receiver through the mail in one large 

12 addressed envelope, similar to "bounding" the transmission with the interchange control header. 

1 3 Since the invoices, purchase orders, and requests for quotation are routed to different offices 

14 upon receipt, the originator might elect to place the three groups of documents into three smaller 

1 5 envelopes with addresses of the various offices, similar to "bounding" each category of 

1 6 transaction sets with functional group headers and trailers. 

17 Like ANSI ASC X12, UN/EDIFACT is a system of standards which define rules for 

1 8 EDI and syntax between correspondents. UN/EDIFACT is primarily used outside the United 

1 9 States and/or by mtemational trading partners. Even though the two standards are basically 

20 similar in function and intent, a data translator (or "mapper") must be used to recast X12 code to 

2 1 UN/EDIFACT, or vice-versa. UN/EDIFACT uses the same four groups of standards as ANSI 

22 XI 2: transaction set standards, a data element dictionary, segment dkectory, and transmission 

23 control standards. Similarities and differences between the two are: Both use data elements as the 
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1 basic building block, though UN/EDIFACT uses a somewhat different method for presenting the 

2 data element. UN/EDIFACT uses a "composite data element" which only recently is being 

3 accommodated within XI 2. The composite data element consists of two or more simple data 

4 elements linked together. The composite shows functional relationships between the elements so 

5 that the same grouping is used consistently. Data segments in the two systems are broadly 

6 similar. UN/EDIFACT uses data elements in the construction of segments and some controls for 

7 repetitive counting; features not used in ANSI X12. The UN/EDIFACT equivalent to the ANSI 

8 X12 "transaction data set" is the "message". Both require the user to follow a structured 

9 sequence to create the document, and the resulting overall design is very similar. Differences in 

10 allowed character sets do not affect message design, but might be of concern when the sender 

1 1 selects delimiter characters for segments and elements. Grouping of transaction sets (or messages 

12 in UN/EDIFACT) for transmission is broadly similar in the two systems, though UN/EDIFACT 

1 3 does not requke use of fimctional group headers and trailers. 

14 Another common data standard for financial transactions is X9, which like X12, is 

1 5 accredited by ANSI and developed, established, published and maintained for facilitate delivery 

1 6 of fmancial products and services in the financial services industry using voluntary, consensus 

17 technical standards. The inter-industry voting membership of the X9 committee includes over 

1 8 300 organizations representing investment managers, banks, software and equipment 

1 9 manufacturers, printers, credit unions, depositories, government regulators, associations, 

20 consultants, and others. X9 develops for check processing, electronic check exchange, PIN 

2 1 management and security, financial mdustry use of data encryption, and wholesale funds 

22 transfer, among others. Standards under development as of 1 999 include electronic payments on 

23 the internet, fmancial image interchange, home banking security requirements, institutional trade 
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1 messages, and electronic benefits transfer. Specifically, X9 deals with paper-based financial 

2 instruments, as well as the MICR line of US-based checks, thereby facilitating the movement 

3 away from paper-based transactions and towards e-commerce-based transactions, as well as the 

4 integration of and interaction between e-commerce and EDI systems of varying methods. 

5 Despite the ultimate goal of EDI to standardize transactions, there is no true single 

6 standard governing the format of a transaction, as a practical matter. Even within the Federal 

7 Government, each agency has a different system and requirements. Instead, there are multiple 

8 data dictionaries defining transaction formats, with multiple versions which proliferate the 

9 business world, both domestically and globally. In addition to the X12 document sets discussed 

10 above, other formats include UN/EDIFACT (United Nations rules for Electronic Data 

1 1 Interchange For Administration, Commerce and Transport), CEFACT (Centre for Facilitation of 

12 Procedures and Practices for Administration, Commerce and Transport), NACHA (National 

13 Automated Clearinghouse Association), and SWIFT (Society for Worldwide Interbank Financial 

14 Telecommunications). From year to year, each of these data dictionaries is updated and a new 

1 5 version is issued. The update includes the addition of new "codes", or entries, to the data 

16 dictionary, the deletion of codes, as well as modifications of existing codes. For example, as of 

17 the year 1999, at least 13 different versions of X12 were in existence (version 2000 through 

18 version 4030). In a typical X12 version, over 63 data segments, 630 fields of information, and 

19 10,000 codes exist for financial EDI. These statistics are compounded with each and every X12 

20 version. 

21 In a typical EDI environment, a set of tables defining each X12 segment, field and 

22 looping structure must be created. With the release of each X12 version, a new and separate set 

23 of tables is required. This approach is cumbersome and requires much recasting of data from 



12 



1 one format to another. Additionally, such a complicated approach necessitates the hiring of 

2 programmers to write many lines of code, as each data dictionary for each format is updated 

3 from year to year. Moreover, with the multiple data dictionaries that define transaction formats, 

4 such as UN/EDIFACT, CEFACT, NACHA, and SWIFT, as well as the multiple versions which 

5 proliferate the business world, both domestically and globally, there is a need for data 

6 normaUzation among the data dictionaries of each of the transaction formats, as well as among 

7 the multiple versions of each format There is also a need for data normalization between data 

8 dictionaries of the foregoing transaction formats and other data formats, such as print image files, 
SQL data sources, and fixed record ASCII. There is further a need for data normalization 

f^iO between data dictionaries of the foregoing transaction formats and legacy paper-based financial 

Jfl 1 transaction instruments (e.g. checks, cashier's checks, drafts, and other financial instruments). 



m SUMMARY OF THE INVENTION 

tJ3 It is therefore an object of the present invention to normalize a plurality of transaction 

i3l4 format defining data dictionaries with one another. 

Ql 5 It is another object of the present invention to normalize a plurality of versions of a 

16 transaction format defining data dictionary with one another. 

17 It is a fiirther object of the present invention to normalize data of one or more 

1 8 transaction format defining data dictionaries with other data formats, such as print image files, 

1 9 SQL data sources, and fixed record ASCII. 

20 It is yet a further object of the present invention to normalize data of one or more 

21 transaction format defining data dictionaries with legacy paper-based financial transaction 

22 instruments. 
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1 It is still another object of the present invention to provide a system and method for 

2 translating transaction data using a data normalization-based translation engine. 

3 It is still a further object of the present invention to provide improved performance and 

4 simplified storage in a system for processing transactions in an EDI environment. 

5 It is still yet a further object of the present invention to provide a web-based data 

6 normalization portal for translating transaction data. 

7 The present invention involves the normalization of a plurality of varying data 

8 dictionaries and versions of data dictionaries into a single set of tags, which are then used to 

9 create one or more payment formats. This normaUzed approach simplifies data storage and 

10 significantly improves the performance of processing financial transaction based data and files. 

1 1 In one embodiment of a system according to the present invention, a plurality of 



12 transaction format defining data dictionaries are normalized into a single set of tags, and the 

13 relationships between those tags (and thus the corresponding fields of the underlying data 

14 dictionaries) is also normalized. These tags, which include a plurality of predefined data fields, 

1 5 are then used as a core data structure for the data translation process. A first dictionary 

16 corresponds to the input format of the data to be translated. The first dictionary is used to locate 

17 within the transaction data to be translated data which corresponds to at least a portion of the 

1 8 predefined data fields. The input data is then translated into the core format. A second 

19 dictionary corresponds to the intended output data format and is used to assemble output 

20 transaction data using the core-formatted data representing at least a portion of the predefined 

21 data fields. 

22 In method form, the normalization method comprises the steps of: receiving input 

23 transaction data in an input data format; using at least a first dictionary corresponding to said 



14 



1 input data format to locate, within said input transaction data, data corresponding to at least a 

2 portion of the predefined data fields of a core data structure having a plurality of predefined data 

3 fields; and using at least a second dictionary corresponding to at least one output data format to 

4 output transaction data in said output data format, said output transaction data corresponding to 

5 at least a portion of the predefined data fields of said core data structure. 

6 A preferred embodiment of the present invention is a web-based transaction data 

7 normalization portal comprising a core data structure having a plurality of predefined data fields, 

8 at least one first dictionary corresponding to at least one input data format, at least one second 
O9 dictionary corresponding to at least one output data format, and a translation engine residing on a 
!?j 0 network server adapted for communication with a network. The translation engine receives fi-om 
jjj 1 a first computer, via said network, input transaction data in said uiput data format. The 

2 translation engine uses said fu-st dictionary to locate, within said input transaction data, data 

U 3 corresponding to at least a portion of the predefined data fields of said core data stinicture. The 

5^4 translation engine tiien uses said second dictionary to output to a second computer, via said 

5 5 network, output tt-ansaction data in said output data format, said output tiansaction data 

1 6 corresponding to at least a portion of the predefined data fields of said core data structure. 

1 7 In one embodunent, tiie method of the transaction data normalization portal includes the 

1 8 steps of: receivmg from at least a first computer, via a network, input transaction data m an input 

1 9 data format; using at least a first dictionary corresponding to said input data format to locate, 

20 witiiin said input ti-ansaction data, data corresponding to at least a portion of the predefined data 

2 1 fields of a core data stincture having a plurality of predefmed data fields; and using at least a 

22 second dictionary corresponding to at least one output data format to output to a second 

23 computer, via said network, output transaction data in said output data format, said output 



15 



1 transaction data corresponding to at least a portion of the predefined data fields of said core data 

2 structure. 

3 BRIEF DESCRIPTION OF THE DRAWINGS 

4 Figure 1 is a block diagram representation of an embodiment of a transaction data 

5 translator according to the present invention; 

6 Figure 2 is an example of input transaction data which may be received in one 

7 embodiment of the present invention; 

8 Figure 3 is a graphical representation of example EDI transaction data of a portion of 

9 the first dictionary in one embodiment of the present invention; 

10 Figure 4 is a graphical representation of a portion of the first dictionary in one 

1 1 embodiment of the present invention; 

12 Figure 5 is a graphical representation of a portion of the core data structure in one 

1 3 embodiment of the present invention; 

14 Figure 6 is a graphical representation of a portion of the second dictionary in one 

1 5 embodiment of the present invention; 

16 Figure 7 is a process flow diagram of the operation of a translation engine according to 

17 one embodiment of the present invention; and 

1 8 Figure 8 is a system diagram of a preferred embodiment of a translation engine 

19 according to the present invention integrated into a network setting. 

20 It will be appreciated by those skilled in the art that although the following Detailed 

2 1 Description will proceed with reference being made to preferred embodiments, the present 

22 invention is not intended to be limited to these embodiments. For example, it should be 

23 understood from the outset that although preferably the functional components of the preferred 
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1 embodiments of the system of the present invention are embodied as one or more distributed 

2 computer program processes, data structures, dictionaries or other stored data on one or more 

3 conventional general purpose computers (e.g. IBM-compatible, Apple Macintosh, and/or RISC 

4 microprocessor-based computers), conventional teleconmiunications (e.g. modem and/or ISDN 

5 communications), memory storage means (e.g. RAM, ROM) and storage devices (e.g. computer- 

6 readable memory, disk array, direct access storage) networked together by conventional network 

7 hardware and software (e.g. LANAVAN network backbone systems and/or Internet), other types 

8 of computers and network resources may be used without departing from the present invention. 
O 9 The invention as described herein may be embodied in a computer residing on a 

flO network transaction server system, and input/output access to the invention may comprise 

]^ 1 appropriate hardware and software (e.g. personal and/or mainfimne computers provisioned with 

;il2 Internet wide area network communications hardware and software (e.g. CQI-based, FTP, 

nl 3 Netscape Navigator^^ or Microsoft Internet Explorer^^ HTML Internet browser software, and/or 

1314 direct real-time TCP/IP interfaces accessing real-time TCP/IP sockets) for permitting human 

015 users to send and receive data, or to allow unattended execution of various operations of the 

16 invention, in real-time and/or batch-type transactions. Likewise, it is preferred that the system of 

1 7 the present invention be a remote internet-based server accessible through conventional 

18 communications channels (e.g. conventional telecommunications, broadband communications, 

19 wireless conmnmications) using conventional browser software (e.g. Netscape Navigator™ or 

20 Microsoft Internet Explorer™). Thus, the present invention is preferably appropriately adapted 

21 to include such communication fimctionality and intemet browsing ability. Additionally, those 

22 skilled in the art will recognize that the various components of the server system of the present 

23 invention can be remote from one another, and may fiirther comprise appropriate 
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1 communications hardware/software and/or LANAVAN hardware and/or software to accomplish 

2 the functionality herein described. 

3 Preferably, each of the functional components of the present invention are embodied as 

4 one or more distributed computer program processes running on one or more conventional 

5 general purpose computers networked together by conventional networking hardware and 

6 software. Most preferably, each of these functional components is embodied by running 

7 distributed computer program processes (e.g., generated using "full-scale" relational database 

8 engines such as IBM DB2™, Microsoft SQL Server™, Sybase SQL Server™, Oracle 7.3 ™, or 

9 Oracle 8.0 ™ database managers, and/or a JDBC interface to link to such databases) on 

10 networked computer systems (e.g. comprising mainframe and/or symmetrically or massively 

1 1 parallel computing systems such as the IBM SB2 ™ or HP 9000 ™ computer systems) including 

12 appropriate mass storage, networking, and other hardware and software for permitting these 

13 functional components to achieve the stated function. Preferably, these computer systems are 

14 geographically distributed and connected together via appropriate wide- and local-area network 

15 hardware and software. In one embodiment, program data can be made accessible to the user via 

16 standard SQL queries for analysis and reporting purposes. 

1 7 Primary elements of the invention can be server-based and can reside on hardware 

1 8 supporting an operating system such as Microsoft Windows NT/2000™ or UNIX. Clients can 

19 include a PC that supports Microsoft Windows 95/98/NT/ME/2000 ™ or a UNIX Motif 

20 workstation platform. In a preferred embodiment, no software other than a web browser is 

2 1 required on the client platform. 

22 Alternatively, the aforesaid functional components may be embodied by a plurality of 

23 separate computer processes (e.g. generated via dBase ™, Xbase ™, MS Access ™ or other "flat 
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1 file" type database management systems or products) running on IBM-type, Intel Pentium or 

2 RISC microprocessor-based personal computers networked together via conventional networking 

3 hardware and software and including such other additional conventional hardware and software 

4 as is necessary to permit these fimctional components to achieve the stated fimctionalities. In 

5 this alternative configuration, since such personal computers typically are unable to run full-scale 

6 relational database engines of the types presented above, a non-relational flat file "table" (not 

7 shown) may be included in at least one of the networked personal computers to represent at least 

8 portions of data stored by a system according to the present mvention. Preferably, these personal 
O9 computers run the Unix, Microsoft Windows NT/2000 ™ or Windows 95/98/ME ™ operating 
flo system. The aforesaid fimctional components of a system according to the present invention 

!1 1 may also comprise a combination of the above two configurations (e.g. by computer program 

Ift 2 processes running on a combination of personal computers, RISC systems, mainframes, 

1=13 symmetric or parallel computer systems, and/or other appropriate hardware and software, 

5 4 networked together via appropriate wide- and local-area network hardware and software). 
|=il 5 A system according to the present invention may also be part of a larger computerized 

1 6 bill presentment and payment system comprising multi-database or multi-computer systems or 

1 7 ' Varehouses" wherein other data types, processing systems (e.g. transaction, financial, 

1 8 administrative, statistical, data extiracting and auditing, data transmission/reception, and/or 

1 9 accounting support and service systems), and/or storage methodologies may be used in 

20 conjunction with those of the present invention to achieve an overall information management, 

2 1 processing, storage, search, statistical and retrieval solution for a particular lock box service 

22 provider, e-payment warehouser, biller organization, financial institution, payment system, 

23 commercial bank, and/or for a cooperative or network of such systems. 
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1 As those in the art will recognize, another possible embodiment of the invention 

2 includes two-way data encryption and digital certification for data being input and output, to 

3 provide security to data during transfer. A further embodiment may comprise security means 

4 including one or more of the following: password or PIN number protection, use of a 

5 semiconductor, magnetic or other physical key device, biometric methods (including fingerprint, 

6 nailbed, palm, iris, or retina scanning, handwriting analysis, handprint recognition, voice 

7 recognition, or facial imaging), or other log-on security measures known in the art. 

8 In a preferred embodiment, source code is written in an object-oriented programming 

9 language using relational databases. Such a preferred embodiment includes the use of 

10 programming languages such as Java, and certain functions, such as remote payer access, are 

1 1 accomplished using an application server platform (ASP) such as Safika's NetDynamics™. 

12 Other programming languages which can be used in constructing a system according to the 

13 present invention include C/C++, HTML, Perl, UNIX shell scripting, assembly language, 

14 Fortran, Pascal, Visual Basic, and QuickBasic. Those skilled in the art will recognize that the 

15 present invention may be implemented in hardware, software, or a combination of hardware and 

16 software. The preferred translation engine of the present invention resides in computer-readable 

17 memory having a resident algorithm for performing the translation of data as described and 

18 claimed herein. 

19 The translation of EDI-type financial data, particularly of the X12, UN/EDIFACT, and 

20 NACHA formats, as discussed herein, is provided herein only as an example of transaction data 

2 1 capable of interacting with the invention and should not be construed so as to limit the use of the 

22 invention solely in such a setting. While the discussion herein presumes the use of the invention 
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1 with respect to EDI, transactional, or financial data, it is anticipated that the invention may have 

2 utility in other contexts, as well, 

3 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

4 With reference now being made to Figure 1, preferred embodiments of the system and 

5 process of the present invention will now be described. Preferred embodiment 200 comprises a 

6 core data structure 203, a first dictionary 201, a second dictionary 202, and a translation engine 

7 205 receiving input data 204 and outputting output data 206. While only a first and second 

8 dictionary are described herein with respect to the preferred embodiment for ease of reference, 

9 those skilled in the art will recognize that a pluraHty of dictionaries may be required in order to 

10 handle the various input and output formats, one dictionary corresponding to each input or output 

1 1 format. In the preferred embodiment, the input data 204 and output data 206 comprise EDI 

12 transaction data. Input data 204 and output data 206 can be of one or more of the following 

13 formats: X12 (any or all versions, with any looping structure), UN/EDIFACT, CEFACT, 

14 NACHA, SWIFT, print image files, SQL data sources, fixed record ASCII, legacy paper-based 

15 financial transaction instruments (e.g. checks, cashier's checks, drafts, and other financial 

1 6 instruments), any combination of one or more of the foregoing formats, or any other data format. 

1 7 The core data structure 203 is preferably of an XML (extended markup language) or 

1 8 similar format, but can be of any data format, and comprises a set of fields, commonly referred to 

19 as XML "tags". Ideally, the core data structure 203 is a single set of XML tags, each tag 

20 corresponding to a field or to part of a field in each input and/or output data format, such that at 

2 1 least one tag exists in the core data structure to represent each data component or sub-component 

22 of each input and/or output data format. The first dictionary 201 corresponds to the input format 

23 of the input transaction data 204 to be translated and is operable to locate within the input data 
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1 204 data which corresponds to at least a portion of the predefined data fields of core data 

2 structure 203 . The second dictionary 202 corresponds to the intended output data format and is 

3 operable to assemble output data 206 using the core-formatted data representing at least a portion 

4 of the predefined data fields of core data structure 203. First dictionary 201 may also be used as 

5 an output dictionary for translating data into the format of the first dictionary, and second 

6 dictionary 202 may also be used as an input dictionary for translating data fi-om the format of the 

7 second dictionary into another format. Alternatively, a separate input and output dictionary may 

8 be used for each input and/or output data format. Translation engine 205 receives input data 204 

9 in an input data format to be translated and outputs output data 206 in a desired ou^ut format. 

10 While the first dictionary 201 , the second dictionary 202, and the core data structure 203 are 

1 1 generally referred to herein as separate components from the translation engine 205, the first 

12 dictionary 20 1 , the second dictionary 202, and the core data structure 203 may also be 

1 3 components of translation engine 205 . 

14 In operation, the translation engme 205 of system 200 receives input transaction data 

15 204. An example of input data 204 which may be received by system 200 for translation may be 

1 6 seen in Figure 2. In Figure 2, the input data 204 shown represents an electronic check document, 

1 7 with a plurality of fields 250. It is noted that the example transactions and data described and 

1 8 shown herein are for illustrative purposes only and include a limited number of fields so that they 

19 can be easily represented in a single diagram. Of course, in an actual embodiment of the present 

20 invention, a transaction may contain a larger or smaller number of fields than is represented 

21 herein. Returning now to Figure 1, translation engine 205 identifies the format of the transaction 

22 contained in input data 204 to determine which data dictionary from among a plurality (not 

23 shown) of dictionaries is to be used as the first dictionary 201 to translate the input data 204 into 
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1 the format of the core data structure 203. Using the first dictionary 201, the translation engine 

2 205 then translates the input data 204 from the input format into the format of the core data 

3 structure 203. 

4 With reference now to Figures 3 and 4, an example of first dictionary 201 in one 

5 embodiment of the invention may be seen. Figure 3 is a graphical representation of the EDI data 

6 shown in Figure 2 as the data would appear on a legacy paper check, and Figure 4 is a graphical 

7 representation of a portion of the first dictionary 201 used in the translation of the check data. In 

8 an actual embodiment, the first dictionary 201 is substantially larger than the portion represented 

9 herein, which is for illustrative purposes only. In Figure 4, "<CHK>" identifies that the data 

1 0 which follows relates to an electronic check document transaction. Fields 1 0 1 through 11 2 of 

1 1 Figure 4 correspond to the fields of Figure 3 to represent the check data contained in the 

12 transaction of Figure 2. For each field, first dictionary 201 contains information including the 

13 segment or field identifier 271, the contents of the field 272, whether the field is required or not 

14 273 (i.e. whether the transaction can be effected without the field), and the required format 274 

15 for the field. 

16 Referring now to Figure 5, a portion of the core data structure 203 in one embodiment 

17 of the invention is shown, comprising mapping (i.e. translating) instructions for relating field 

18 identifiers 271 fi-om first dictionary 201 (as seen in Figure 4) to the appropriate core data 

19 structure elements 279. In an actual embodiment, the core data structure 203 is substantially 

20 larger than the portion represented herein, which is for illustrative purposes only. It is noted that, 

21 for example, field 109 contains data for two fields of the core data structure, Payor Financial 

22 Institution Address 1 and Payor Financial Institution Address 2. As shown in Figure 5, mapping 

23 instructions are provided therein so that field 109 is properly split into the two corresponding 
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1 fields 279 of the core data structure 203. In a similar vein, it is also noted that in this example, 

2 there are no fields within field identifiers 271 which correspond to Payee Address 1 and Payee 

3 Address 2 of the core data structure 203 . Once the input data 204 has been translated into the 

4 format of the core data structure 203, it is available to be translated easily into any desired format 

5 using a second dictionary 202 pre-selected fi-om among a plurality of dictionaries. 

6 Referring once again to Figure 1 , translation engine 205 next translates into the desired 

7 output format the input data 204 which has now been translated into the format of the core data 

8 structure 203. This is accomplished by using the second dictionary 202, which corresponds to 
O 9 the desired output format for the transaction data. Figure 6 shows an example of the second 
f\o dictionary in one embodiment of the invention. In an actual embodiment, the second dictionary 
Jl 1 202 is substantially larger than the portion represented herein, which is for illustrative purposes 
Si 2 only. Just as in Figure 4, "<CHK>" as shown in Figure 6 identifies that the following data is for 
!=t13 an electronic check document transaction. Fields 301 through 314 of Figure 6 correspond to the 
is 14 fields of Figure 3 to represent the check data contained in the transaction of Figure 2, For each 
Q 1 5 field, second dictionary 202 contains information including the segment or field identifier 371, 
~ 1 6 the contents of the field 372, whether the field is required or not 373 , and the required format 374 

17 for the field. Translation engine 205 utilizes second dictionary 202 to determine the data 

1 8 necessary for output, as well as the proper output format for the transaction. Referring now once 

1 9 again to Figure 5 , the portion of the core data structure 203 in one embodiment of the invention 

20 shown comprises mapping instructions for relating field identifiers 371 fi-om second dictionary 

21 202 (as seen in Figure 6) to the appropriate core data structure elements 279. Returning now to 

22 Figure 1 , translation engine 205 utilizes the second dictionary 202 to translate the input data 204 
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1 which has been formatted in the format of the core data structure 203 into output data 206 in the 

2 output format. 

3 Figure 7 shows the operation of translation engme 205 in one embodiment of the 

4 invention. Translation engine 205 initially receives 400 input transaction data in an input format. 

5 The engine identifies 401 the format of the input transaction data and based on the identified 

6 format selects an appropriate fu^t dictionary. The translation engine 205 then translates 402 the 

7 input data into the core data structure using the selected first dictionary. Next, the translation 

8 engine 205 translates 403 the core data structure-translated input transaction data into the desired 

9 output format using a pre-selected second dictionary. Finally, the translation engine 205 outputs 

1 0 404 the ou^ut transaction data in the desired output format. 

11 It is noted that a one-to-one correspondence between the input data structure and the 

12 output data structure is not necessary. Appropriate mapping instructions are contained in the 

13 fu-st dictionary 201 and second dictionary 202 so that proper translation can occur even between 

14 a field of one data format which does not exist in the second, or vice-versa. If the field exists in 

15 the first format but not the second, the data of that field is simply ignored. If the field exists in 

16 the second format but not the first, a default field is supplied. As seen above, some fields must 

1 7 be merged or split in order to achieve proper correspondence between data formats, and 

1 8 dictionaries 20 1 and 202 contain appropriate mapping instructions to achieve such a 

19 correspondence. The following are other examples of mapping instructions contained in 

20 dictionaries 201 and 202 includmg the application of algorithms to conflicts between data 

2 1 formats in the normaUzation process: 

22 As a first example, in one XI 2 version, the DTM (date/time reference) segment 

23 contained the date in the second field of the segment. In the next version, the date was moved to 
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1 the second field to a different field in the segment. In a later version, the field was extended for 

2 century (year 2000) compliance, i.e. to include two extra digits representing the century, and 

3 moved once again. To account for such conflicts, algorithms are defined and applied herein in 

4 the form of mapping instructions, particularly in cases where segments have been recast outside 

5 the rules of data normalization. 

6 As a second example, the core data structure may have a field called "date/time". The 

7 input data 204 structure may have a field defined by the first dictionary 201 as "date" and 

8 another field defined as time "time". Therefore, the algorithm of the first dictionary 201 would 

9 comprise mapping instructions between the core data structure 203 and the first dictionary 201 

10 such that the date/time field of the core data structure 203 is mapped to both the data field and 

1 1 the time field of the first dictionary 201. In operation, the translation engine 205 would start 

12 with the predefined date/time field, look at the mapping algorithm of the first dictionary 201 to 

13 find a date field and a time field, and then use the dictionary to find data corresponding to the 

14 date field and the time field in the input data 204, 

15 As a third example, the date/time field of the core data structure 203 may be formatted 

16 as DDMMYYYYHHMMSS. The date field as defined by the first dictionary 201 may be 

17 formatted as YYMMDD. Therefore, once that data is found in the mput data 204, the data must 

1 8 be reformatted or reorganized (and two digits representing the century must be added) so that it 

1 9 can be fit into the core data structure 203 . 

20 As a fourth example, a data field or segment may need resizing to effect a proper 

21 correspondence between data formats. The first dictionary 201 may contain instructions to add or 

22 remove leading or trailing zeros to make a particular piece of data fit the appropriate size of the 

23 corresponding field. 
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1 As a fifth example, if the input data 204 contains a two-digit year as part of a date field, 

2 the remaining two digits of the year need to be added if the output format requires a four-digit 

3 year as part of the date field. 

4 While the foregoing examples refer only to the first dictionary 20 1 , any of the examples 

5 are applicable to the second dictionary 202, and any of the foregoing examples of algorithms can 

6 also be included in the second dictionary 202. Moreover, the foregoing are merely examples of 

7 mapping algorithms contained in the first dictionary 201 and the second dictionary 202, and 

8 those skilled in the art will recognize that the algorithms of the data dictionaries are not limited 
'^S to the specific examples given herein, 

[i^O As can be seen in Figure 1, an audit log 210 is included in one embodiment of the 

1 invention, for electronically storing the input transaction data 204 and/or the output transaction 

Ifi2 data 206. Along with the input data and/or output data, a date/time stamp can be added to the 

a 3 data stored in the audit log. Storage of the audit log can be in a database, an ASCII flat file, or 

Q4 other file format, and can exist in any form of computer-readable memory, including hard disk, 

Q.5 disk array, removable media, diskette, or other storage medium. 

16 As can be seen in Figure 8, in one embodiment, the system 200 can be part of a 

17 computer network 550, so that the system receives mput transaction data 204 fi"om a computer 

18 500 via the network and/or sends output transaction data 206 to a computer 501 via the network, 

19 Returning again to Figure 1, when the system 200 is part of a network 550, the audit log can 

20 further include transaction identification data 502, i.e. data identifying the computer from which 

21 the input transaction data 204 was sent and/or data identifying the computer to which the output 

22 transaction data 206 was sent. Transaction identification data 502 stored in the audit log can also 



27 



1 include data identifying a user using the computer from which the input data was sent, so that the 

2 audit log comprises a complete transaction history log, or audit trail. 

3 Figure 8 shows another embodiment of the present invention providing warehousing 

4 storage capabilities, i.e. the system can store a transaction after it is translated into the core 

5 structure. Once a first input transaction 204 is stored in warehousing storage 560, one or more 

6 additional transactions 204 of differing type from the first can be received by the system, 

7 translated into the core structure, and then an output transaction 206 can be constructed using the 

8 data from the additional transaction(s), supplemented by data from the first stored transaction. 
O 9 Additionally, a phirality of input transactions 204 can be received, translated into the core 
^10 structure, and stored in warehousing storage 560. Along with the input transactions 204, 

2 1 1 transaction identification information 502 can be stored, inchiding data identifying the computer 

12 from which the input transaction data was sent 503, data identifying the computer to which the 

U 13 output transaction file will be sent 504, and^r data identifying a user using the computer fi-om 

[5 14 which the input data was sent 505. Thus, an output transaction 206 can be constructed using 

5 1 5 stored transaction data in the core data structure, originating from the phxralify of input 

^ 16 transactions 204. The data used in constructing the output transaction 206 can be selected based 

17 on the stored transaction identification data 502 accompanying the stored transaction data. The 

1 8 warehousing storage 560 can be embodied as a component of the translation system 200, or 

19 alternatively, can exist as a separate component outside of the system 200. 

20 In a fixrther embodiment of the present invention, the translation engine is capable of 

2 1 generating a plurality of output transactions from a single input transaction. Each of the output 

22 transactions may be based on portions of the input transaction data not used for the other output 

23 transactions. For example, the input transaction might represent a customer returning 
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1 merchandise to a supplier. In this scenario, the translation engine splits a single return 

2 transaction received as input transaction data into three output transactions: a customer credit 

3 transaction, a return to inventory transaction, and a debit sales transaction. The plurality of 

4 output transactions, in addition to being different types of transactions from one another, can also 

5 be functional duplicates of identical or similar transactions which are sent to different computers 

6 as output transactions. For example, in a retum transaction including data representing returns to 

7 two different sources, the output transactions may both be retum transactions to be received by 

8 two different computers. Another example would be for a retum of item A to source X and a 

9 retum of item B to source Y. The output transactions may comprise output transaction data sent 

10 to computer L at source X for the retum of item A, and output transaction data sent to computer 

11 M at source Y for the retum of item B . 

12 It should be appreciated by those skilled in the art that one or more of the functional 

13 components may be constructed out of custom, dedicated electronic hardware and/or software, 

14 without departing from the present invention. Thus, the present invention is intended to cover all 

15 such alternatives, modifications, and equivalents as may be included within the spirit and broad 

1 6 scope of the invention as defined only by the hereinafter appended claims. 
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1 What is claimed is: 



2 L A system for translating transaction data, said system comprising: 

3 a core data structure having a plurality of predefined data fields; 

4 at least one first dictionary corresponding to at least one input data format; 

5 at least one second dictionary corresponding to at least one output data format; and 

6 a translation engine; 

7 said engine receiving input transaction data in said input data format; 

8 said engine using said first dictionary to locate, within said input transaction 
O9 data, data corresponding to at least a portion of the predefined data fields 
■flO of said core data structure; 

]^ 1 said engine using said second dictionary to output transaction data, in said 

Ml output data format, said output transaction data corresponding to at least a 

(43 portion of the predefined data fields of said core data structure. 

f3 4 2. The system of claim 1 , wherein said input data format comprises data organized in 



as segments and fields; and wherein said first dictionary comprises data representing: identification 

p 

16 of a plurality of segments comprising a plurality of fields, the size of each said field, and an 

1 7 indicator of whether said field is required or optional 

18 3 . The system of claim 1 , wherein said first dictionary comprises mapping instructions to 

19 map a predefined data field in said core data structure to a segment and field in said input data 

20 format to locate data in said input data format corresponding to said predefined data field. 

21 4. The system of claim 3, wherein said first dictionary further comprises an instruction to 

22 reformat said located data to correspond to at least one parameter of said predefined data field. 
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1 5. The system of claim 4, wherein said at least one parameter is at least a parameter of field 

2 size and organization. 

3 6. The system of claim 5, wherein said second dictionary further comprises an instruction to 

4 map a predefined data field in said core data structure to a segment and field in said output data 

5 format, thereby outputting data in said output data format corresponding to said predefined data 

6 field. 

7 7. The system of claim 6, wherein said second dictionary further comprises an instruction to 

8 generate default data to combine with data from said core data structure to output data in said 

9 output data format when said at least one parameter of said output data format requires data 

10 which is not present in said core data structure. 

11 8. The system of claim 1 , further comprising an audit log, said audit log storing said input 

12 transaction data and/or said output transaction data. 

13 9. The system of claim 8, wherein said system is connected to a computer network, said 

14 system receiving said input transaction data fi-om a computer via said network and sending said 

15 output transaction data to a computer via said network, wherein said audit log further stores 

1 6 transaction identification data identifying the computer fi-om which the input transaction data is 

17 sent and/or the computer to which the output transaction file is sent. 

18 10. The system of claim 8, wherein said transaction identification data further comprises data 

19 identifying a user executing an input transaction from the computer fi-om which the input 

20 transaction data is sent. 

21 11. The system of claim 1 , further comprising warehousing storage, wherein said 

22 warehousing storage electronically stores data from at least a first input transaction after said 

23 transaction has been translated into said core data structure. 
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1 12. The system of claim 1 1 , wherein said translation engine is further adapted for receiving 

2 data from at least one additional input transaction, translating said additional input transaction 

3 data into said core data structure, storing said core data structure-translated additional input 

4 transaction data in said warehousing storage, and outputting output transaction data based on a 

5 combination of data from said at least one additional input transaction and from said first stored 

6 input transaction data. 

7 13. The system of claim 12, wherein said warehousing storage further stores transaction 

8 identification data identifying the computer from which the input transaction data is sent, the 
O 9 computer to which the output transaction file is to be sent, and/or data identifying a user 

"'Is? 

0 executing an input trausaction from the computer from which the input transaction data is sent, 

ill 1 wherein said translation engine is further adapted for selecting said combination of data based on 

•=1 2 said transaction identification data. 

nl 3 14. The system of claim 1 , wherein said translation engine is fiirther adapted for generating 

iSu data representing a phirality of output transactions from said input transaction data, wherein said 

Q 1 5 input transaction data represents a single input transaction. 

16 15. The system of claim 1 4, wherein the data of each said output transaction is generated 

17 using at least a portion of said input transaction data not used in the generation of any other of 

1 8 said output transactions. 

19 16. The system of claim 1 4, wherein said output transaction data of at least two of said output 

20 transactions are sent to different computers. 

21 17. The system of claim 1, wherein said translation engine comprises one or more of said 

22 core data structure, said at least one first dictionary, and said at least one second dictionary. 
23 
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1 18. A method of normalizing transaction data, said method comprising the steps of: 

2 receiving input transaction data in an input data format; 

3 using at least a first dictionary corresponding to said input data format to 

4 locate, within said input transaction data, data corresponding to at least a 

5 portion of the predefined data fields of a core data structure having a 

6 plurality of predefined data fields; and 

7 using at least a second dictionary corresponding to at least one output data 

8 format to output transaction data in said output data format, said output 
D 9 transaction data corresponding to at least a portion of the predefined data 
U\ 0 fields of said core data structure. 

1 1 9. The method of claim 1 8, wherein said input data format comprises data organized in 



Sl2 segments and fields; and wherein said first dictionary comprises data representing: identification 

JU 13 of a plurality of segments comprising a plurality of fields, the size of each said field, and an 

p5i4 indicator of whether said field is required or optional. 

0 1 5 20. The method of claim 1 8, wherein said first dictionary comprises mapping instructions to 

16 map a predefined data field in said core data structure to a segment and field in said input data 

17 format to locate data in said input data format corresponding to said predefined data field. 

18 21 . The method of claim 20, wherein said first dictionary further comprises an instruction to 

19 reformat said located data to correspond to at least one parameter of said predefined data field. 

20 22, The method of claim 2 1 , wherein said at least one parameter is at least a parameter of 

21 field size and organization. 

22 23, The method of claim 22, wherein said second dictionary further comprises an instruction 

23 to map a predefined data field in said core data structure to a segment and field in said output 
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1 data format, thereby outputting data in said output data format corresponding to said predefined 

2 data field. 

3 24. The method of claim 23, wherein said second dictionary further comprises an instruction 

4 to generate default data to combine with data from said core data structure to output data in said 

5 output data format when said at least one parameter of said output data format requires data 

6 which is not present in said core data structure. 

7 25. The method of claim 1 8, further comprising the step of storing in an audit log said input 

8 transaction data and/or said output transaction data. 

9 26. The method of claim 25, wherein receipt of said input transaction data and outputting of 

10 said output transaction data is via a computer network, further comprising the step of storing in 

1 1 said audit log transaction identification data identifying the computer firom which the input 

12 transaction data is sent and/or the computer to which the output transaction file is sent. 

13 27. The method of claim 25, wherein said transaction identification data further comprises 

14 data identifying a user executing an input transaction firom the computer firom which the input 

1 5 transaction data is sent. 

16 28. The method of claim 1 8, further comprising the step of electronically storing data fi"om at 

17 least a first input transaction after said transaction has been translated into said core data 

18 structure. 

19 29. The method of claim 18, further comprising the steps of receiving data from at least one 

20 additional input transaction, translating said additional input transaction data into said core data 

21 structure, storing said core data structure-translated additional input transaction data in said 

22 warehousing storage, and outputting output transaction data based on a combination of data from 

23 said at least one additional input transaction and from said first stored input transaction data. 
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1 30. The method of claim 29, further comprising the steps of storing transaction identification 

2 data identifying the computer from which the input transaction data is sent, the computer to 

3 which the output transaction file is to be sent, and/or data identifying a user executing an input 

4 transaction from the computer from which the input transaction data is sent; and selecting said 

5 combination of data based on said transaction identification data. 

6 31. The method of claim 1 8, further comprising the step of generating data representing a 

7 plurality of output transactions from said input transaction data, wherein said input transaction 

8 data represents a single input transaction. 

9 32. The method of claim 3 1 , wherein the data of each said output transaction is generated 

1 0 using at least a portion of said input transaction data not used in the generation of any other of 

1 1 said output transactions. 

12 33. The method of claim 3 1 , further comprising the step of sending said output transaction 

13 data of at least two of said output transactions to different computers. 
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1 ABSTRACT 

2 A financial transaction data translation system and method, preferably embodied in a 

3 web-based portal, includes a plurality of data dictionaries normalizing varying ti-ansaction 

4 formats into a single set of tags and normalizing die relationships between those tags (and thus 

5 the corresponding fields of the underlying data dictionaries). The tags, which include a plurality 

6 of predefined data fields, are then used as a core data stiiicture for the data translation process. A 

7 first dictionary corresponds to the input format of the data to be ti-anslated. The first dictionary is 

8 used to locate within the transaction data to be translated data which corresponds to at least a 

9 portion of the predefmed data fields. The input data is then ti-anslated into the core format. A 

1 0 second dictionary corresponds to the intended ou^ut data format and is used to assemble output 

1 1 transaction data using the core-formatted data representing at least a portion of the predefmed 

12 data fields. 
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